IBIS Macromodel Task Group Meeting date: 20 June 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to submit his proposal as BIRD 190. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 190: - Arpad: Two weeks ago we tabled BIRD 166. - Walter is back today so we could untable it if we want to discuss it. - I'd like to discuss BIRD 166 vs. BIRD 190 and try to come up with a recommendation to the Open Forum on which way to proceed. - Walter had sent an email regarding BIRD 190, so we could discuss that. - No one leaves the meeting until we make a decision ;-) - Walter: I think BIRD 190, with the changes I proposed, would be acceptable. - [reviewing changes to BIRD 190 proposed in the email] - Instances of "Rx" changed to "Rx2" (editorial). - Removed "always default to valid values or" - The important thing is to have a way to accept user defined coefficients and turn off optimization. The phrase "always default to valid values" didn't add anything. - Removed "to ensure successful simulations" - I'm not sure what "successful simulation" means, and I question whether this would ensure accurate simulation results. - Arpad: I think it was trying to say the model should work without having to run its optimizer first, but I understand your point. - Bob M.: The problem is defining "successful simulations." You might end up with a tightly closed eye using some default "valid values." - Walter: [continuing list of changes to BIRD 190] - Add the following sentence at the end: - "An EDA tool may elect to include the upstream channel characteristics and/or equalization effects in the input to the downstream Rx2 AMI_Init function instead of including them in the output of the Rx2 AMI_Init function." - With those changes I think it satisfies Ambrish's intent and I would be able to support it. - Arpad: That last sentence conflicts with the "does not include" sentence earlier in the text. If the first sentence says it "does not include" upstream effects, then the last sentence shouldn't say that it may include them in some cases. - Walter: That first "does not include" sentence describes the prescribed flow. - The last sentence says the EDA tool need not follow the prescribed flow. - Arpad: I understand that. - But we have a flow in the spec, and then that last sentence tells the EDA tools they don't have to follow it. - Walter: The statistical redriver flow in the spec, even if the Rx2 does not optimize itself, will give the wrong answer. - I'm only talking about statistical flow, so all models must have Init_Returns_Impulse = true. - Ambrish: Optimization is the problem. - Walter: No, even if the Rx2 doesn't optimize itself, the current statistical flow gives the wrong answer. - Fangyi/Ambrish: I disagree. - Arpad: Can you explain that Walter? - In your email you mentioned that DFE could be approximated in the Init() function. If it's done there, doesn't it become an LTI approximation and the summation doesn't apply anymore? - Walter: I will give a simple example to illustrate. - Suppose the Rx2 has a DFE, and consider the following example: - 1. Tx1 is an ideal Tx. No equalization, it doesn't do anything. - 2. Upstream channel is an ideal channel (Its IR is a Dirac delta, i.e. unit IR (area = 1)). - 3. Rx1 simply has a gain of 2. - 4. Output of Rx1 is a Dirac delta with an area of two. - 5. Tx2 is also an ideal Tx with no equalization. - 6. Downstream channel is also an ideal channel (Its IR is a Dirac delta). - 7. Rx2 has a DFE tap with a value of -.1. - 8. With the 6.1 flow, the output of Rx2 will be a Dirac delta at zero with an area of 1 and another at 1 UI with an area of -.1. Then you go ahead and convolve with the output of Rx1, which doubles everything. - 9. With the BIRD 166 flow, you get a Dirac delta at zero with an area of 2 and another 1 UI with an area of -.1 (not the -.2 you would get from the 6.1 flow). - So by scaling the output of Rx2 Init() by 2, instead of scaling the input by 2, you get two very different answers. Only BIRD 166 gives you the right answer. - That's a plain vanilla scenario that shows the IBIS 6.1 statistical redriver flow is incorrect. - Fangyi: It's up to the model to normalize the slicer output. That shouldn't scale with the input. - Bob M.: But when you do the scaling (convolution with Rx1 output) after the fact it ends up looking like it does. - Fangyi/Ambrish: You have GetWave(). - Walter: No, I'm talking strictly about statistical flow. - Arpad: How do we proceed? Can we discuss Walter's revisions to BIRD 190? - Fangyi: I think Walter's last sentence just reintroduces BIRD 166 again. - Ambrish: That additional sentence in the note will not change the official flow, the results would still be different. The EDA tool could always do something outside the recognized flow in the spec anyway. - Bob M.: I understand the objection to the way Walter's sentence is basically trying to slide BIRD 166 in through the back door. - But that sentence is trying to accomplish something. - The emphasis of the basic BIRD 190 statement is telling model makers and users of statistical models that if you are doing a redriver simulation you get no support from us. - If the sentence Walter is trying to add isn't accepted in some form, then I'd rather just see BIRD 190 tabled as well, because all it's doing is enforcing a statement that if you want to write Init() models you're out of luck. - Arpad: BIRD 190 wasn't intended to solve any technical problems, just to alert the user/reader to an existing limitation in the spec. - Adding Walter's sentence goes back to trying to solve a technical problem. - Bob M.: But Walter's non-adaptation example showed the existing flow is wrong. - Arpad: The problem was we couldn't agree on a technical solution to go into IBIS 7.0. - If we had a good technical solution, for example a variant of Fangyi's proposal, then I would be all for it. - But I think we all agree we don't have enough time to do that before 7.0. - Walter: We all have to recognize and accept that IBIS 6.1 gives the wrong answer. - I think anything that suggests or reinforces a flow that is almost guaranteed to give the wrong answer is unacceptable. - I recommend BIRD 190 not be approved without the added sentence. - I don't mind tabling BIRD 190 along with BIRD 166 and ending this discussion for IBIS 7.0. - I think we've fully documented the flow issues (minutes, emails, etc.) - We could write a white-paper or known issues document, to which we could all contribute, instead of modifying the spec right now. - If we want to change the flow or add that last sentence, I'm okay with that. - Discussion: Walter proposed a straw man poll with several options for how to proceed including tabling both BIRD 166 and BIRD 190, adopting BIRD 190, or adopting BIRD 190 with Walter's additional sentence. Bob R. and Radek suggested we also include Fangyi's proposal amongst the options. Radek noted that with AMI versioning Fangyi's proposal would effectively address the legacy model issue because they could be upgraded to the newer version if necessary. Fangyi confirmed his willingness to work on an official BIRD draft of his proposal. Bob R. said we could see if it could make it into IBIS 7.0. The final straw poll choices were: 1. Table BIRD 166 and BIRD 190. 2. Adopt BIRD 190 as submitted to the Open Forum. 3. Adopt BIRD 190 with Walter's modifications. 4. Consider going forward with Fangyi's proposal (perhaps for 7.0). Organizations voted for the options as follows: ANSYS: 1, 4 Broadcom: 1, 4 Cadence: 2, 4 Intel: 1 Keysight: 2, 4 Mentor: 1, 2, 4 Micron: Abstain SiSoft: 1 Teraspeed: 1, 4 - Walter: I think consensus is that we should table both BIRD 166 and BIRD 190. - This group also proceeds with Fangyi's proposal. - I think we should also create a known-issues list for the current spec. - Ambrish: Can we file a bug report? - Arpad/Radek: We don't have bug reports against the spec itself. - Radek: A "known issues" idea is okay. - I'm not sure we have anything like that on the website currently. - We have documentation via meeting minutes, working directories, etc., but they might not be that easily accessible to new readers or visitors. - Arpad: Anything modifying the spec needs a BIRD. - But perhaps we could start a new known issues document. - Bob R.: Main conclusion is that after we introduce BIRD 190 we should immediately table it in the Open Forum. - We can table BIRD 190 here in the ATM next time. - Radek: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 27 June 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives